.editorconfig (1)

14-16: A trifle incomplete — consider shielding lock files more fully.

The section wisely unsets indent_size and insert_final_newline to ward off needless diffs upon the machine-forged lock files. Yet trim_trailing_whitespace is left to inherit true from the global realm. While pnpm-lock.yaml shall not wander into trailing whitespace of its own accord, unsetting it fully would guard against any meddlesome editor tool that might alter what it ought not touch.

🔮 Proposed refinement for the lock file section

 [{pnpm-lock.yaml,*.lock}]
 indent_size = unset
 insert_final_newline = unset
+trim_trailing_whitespace = unset

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.editorconfig around lines 14 - 16, The .editorconfig section for
[{pnpm-lock.yaml,*.lock}] currently unsets indent_size and insert_final_newline
but leaves trim_trailing_whitespace inherited (true); update that section by
adding trim_trailing_whitespace = unset so the lock-file pattern in
.editorconfig (the [{pnpm-lock.yaml,*.lock}] section) explicitly disables
trimming trailing whitespace.

packages/nuxt/vitest.config.ts (1)

4-21: Eliminate the dual source of truth between tsconfigRaw and tsconfig.test.json.

The compilerOptions block inside tsconfigRaw on Lines 7–15 is a verbatim copy of what already lives in tsconfig.test.json. Importing that file directly removes the duplication — and JSON.stringify is also unnecessary since tsconfigRaw accepts a plain object.

♻️ Suggested simplification

 import { fileURLToPath } from 'node:url'
 import { defineConfig } from 'vitest/config'
+import tsconfigRaw from './tsconfig.test.json'

 export default defineConfig({
   esbuild: {
-    tsconfigRaw: JSON.stringify({
-      compilerOptions: {
-        target: 'ES2020',
-        module: 'ESNext',
-        moduleResolution: 'bundler',
-        strict: true,
-        esModuleInterop: true,
-        skipLibCheck: true,
-        allowSyntheticDefaultImports: true,
-      },
-    }),
+    tsconfigRaw,
   },
   test: {
     globals: false,
     root: fileURLToPath(new URL('.', import.meta.url)),
   },
 })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/vitest.config.ts` around lines 4 - 21, The tsconfigRaw object
in defineConfig duplicates compilerOptions already present in
tsconfig.test.json; replace the inline JSON.stringify block with an imported
object reference by reading/parsing tsconfig.test.json and assigning its
compilerOptions (or the whole config) directly to tsconfigRaw (no JSON.stringify
needed). Locate the defineConfig call and the tsconfigRaw property in
vitest.config.ts, import or require the tsconfig.test.json, and set tsconfigRaw:
importedConfig (or tsconfig.test.json.compilerOptions) to remove the duplicate
source of truth.

packages/nuxt/tsconfig.test.json (1)

1-13: Consider extending the base tsconfig to prevent strict-settings drift in tests.

This config stands alone without extending the root or packages/nuxt/tsconfig.json. In consequence, several strict flags present in the root (noUncheckedIndexedAccess, exactOptionalPropertyTypes, noImplicitOverride, noUnusedLocals, etc.) are absent here. Test code will not be checked against the same rigour as production source, which can mask real bugs.

♻️ Suggested approach

 {
+  "extends": "../../tsconfig.json",
   "compilerOptions": {
     "target": "ES2020",
     "module": "ESNext",
     "moduleResolution": "bundler",
     "strict": true,
     "esModuleInterop": true,
     "skipLibCheck": true,
-    "allowSyntheticDefaultImports": true
+    "allowSyntheticDefaultImports": true,
+    "noEmit": true
   },
   "include": ["src", "test"],
-  "exclude": ["node_modules", "dist"]
+  "exclude": ["node_modules", "dist"],
+  "references": [{ "path": "../core" }]
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/tsconfig.test.json` around lines 1 - 13, The test tsconfig
(tsconfig.test.json) is missing an "extends" reference so test builds drift from
root strict compiler settings; update tsconfig.test.json to extend the
central/base tsconfig (so it inherits strict flags like
noUncheckedIndexedAccess, exactOptionalPropertyTypes, noImplicitOverride,
noUnusedLocals, etc.), keep or override only test-specific compilerOptions
(e.g., moduleResolution, target) and preserve "include": ["src","test"] and
"exclude": ["node_modules","dist"] — ensure the "compilerOptions" in
tsconfig.test.json only contains intentional overrides and that common strict
flags come from the base config.

packages/nuxt/test/middleware.test.ts (1)

241-256: Only the negative POST path is tested for double-submit; the happy path is absent.

There is no test asserting that a POST carrying a valid token and matching cookie is accepted. Without it, a regression that rejects all POSTs would pass the suite silently.

✅ Suggested additional test

it('should accept POST with matching token for double-submit', async () => {
  const adapter = new NuxtAdapter()
  const protection = createCsrfProtection(adapter, {
    strategy: 'double-submit',
  })

  // First issue a token via GET
  const getEvent = createGetEvent()
  await protection.protect(getEvent, getEvent)
  const issuedToken = getResponseHeaders()['x-csrf-token']!

  vi.clearAllMocks()

  // Submit it back in header + cookie
  const postEvent = createPostEvent(
    'http://localhost/api',
    { 'x-csrf-token': issuedToken },
    { 'csrf-token': issuedToken },
  )
  const result = await protection.protect(postEvent, postEvent)

  expect(result.success).toBe(true)
})

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/test/middleware.test.ts` around lines 241 - 256, Add a
positive-path unit test verifying the double-submit flow: use NuxtAdapter and
createCsrfProtection(strategy: 'double-submit'), call protection.protect with a
GET event (use createGetEvent) to obtain the issued token from
getResponseHeaders()['x-csrf-token'], then clear mocks and submit a POST event
(use createPostEvent) that sends the token both in the header ('x-csrf-token')
and as a cookie ('csrf-token'), call protection.protect for the POST and assert
result.success is true; reference NuxtAdapter, createCsrfProtection,
createGetEvent, createPostEvent, getResponseHeaders, and protection.protect to
locate where to add the test.

packages/nuxt/src/runtime/plugin.client.ts (1)

12-16: Duplicate publicConfig type casting — consider a shared type.

The same inline type { cookieName?: string; headerName?: string } | undefined cast appears verbatim in packages/nuxt/src/runtime/composables/useCsrfFetch.ts (lines 23–28). Defining this once (e.g., CsrfArmorPublicConfig) prevents drift if the config shape grows.

♻️ Proposed extraction

Create a shared types.ts under packages/nuxt/src/runtime/:

+// packages/nuxt/src/runtime/types.ts
+export interface CsrfArmorPublicConfig {
+  cookieName?: string;
+  headerName?: string;
+}

Then in both files:

-  const publicConfig = runtimeConfig.public.csrfArmor as
-    | {
-        cookieName?: string;
-      }
-    | undefined;
+  import type { CsrfArmorPublicConfig } from '../types';
+  const publicConfig = runtimeConfig.public.csrfArmor as CsrfArmorPublicConfig | undefined;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/plugin.client.ts` around lines 12 - 16, The inline
duplicate type for publicConfig (the `{ cookieName?: string; headerName?: string
} | undefined` cast used when reading runtimeConfig.public.csrfArmor in
publicConfig and in useCsrfFetch) should be extracted into a single exported
type (e.g., CsrfArmorPublicConfig) in a new shared types file (create types.ts
under the runtime folder), then import and use that type for the casts in both
plugin.client.ts (where publicConfig is declared) and useCsrfFetch.ts to avoid
drift and keep the shape centralized.

packages/nuxt/package.json (1)

69-69: "module" field is redundant with the exports map.

Modern bundlers and Node.js use the exports map (lines 9–13) exclusively; the legacy "module" field at line 69 adds noise without benefit.

♻️ Proposed cleanup

-  "module": "./dist/module.js"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/package.json` at line 69, Remove the redundant "module" field
from package.json: delete the "module": "./dist/module.js" property (it is
superseded by the existing exports map) and ensure the resulting JSON stays
valid (no stray trailing commas); confirm npm/ts/packaging builds still pass and
that the "exports" map remains the single source of module entry points.

packages/nuxt/src/runtime/server/middleware.ts (1)

12-31: A word of counsel on the singleton, if you will hear it.

The csrfProtection singleton is initialized once and never reset. In long-running dev servers with HMR, changes to runtimeConfig.csrfArmor will not take effect until a full restart. This is acceptable for production but worth a comment for clarity.

Also, Line 29: config ?? undefined is redundant — config is already typed as CsrfConfig | undefined, so the nullish coalescing serves no purpose.

🧹 Minor cleanup

-    csrfProtection = createCsrfProtection<H3Event, H3Event>(
-      adapter,
-      config ?? undefined
-    );
+    csrfProtection = createCsrfProtection<H3Event, H3Event>(adapter, config);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/server/middleware.ts` around lines 12 - 31, The
csrfProtection singleton is created once in the default event handler
(csrfProtection, createCsrfProtection, NuxtAdapter, useRuntimeConfig and
runtimeConfig.csrfArmor) which prevents runtimeConfig.csrfArmor changes from
taking effect during long-running dev servers with HMR; add a clear comment
above the initialization explaining this intentional singleton behaviour and
that a full restart is required to pick up runtimeConfig changes in dev, and
remove the redundant nullish coalescing (`config ?? undefined`) when passing
config into createCsrfProtection since config is already typed as CsrfConfig |
undefined.

packages/nuxt/src/runtime/composables/useCsrfToken.ts (2)

11-15: Module-level singletons on the server — heed this counsel.

globalListenersInitialized and resolvedConfig are module-scoped. On the client this is fine (single app instance). On the server, initGlobalListeners is guarded by import.meta.client so it's a no-op — good. But resolvedConfig (Line 15) is set on first invocation and cached indefinitely. Since it's derived from runtimeConfig (which should be constant per deployment), this is acceptable, though it does mean runtime config changes require a process restart.

A brief comment noting this intentional caching would be a kindness to future travelers on this road.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/composables/useCsrfToken.ts` around lines 11 - 15,
The module currently uses module-scoped singletons globalListenersInitialized
and resolvedConfig; add a concise comment near resolvedConfig explaining that
the caching is intentional: resolvedConfig is derived from runtimeConfig and
cached for the lifetime of the process (so changes to runtimeConfig require a
process restart), and note that initGlobalListeners is guarded by
import.meta.client so globalListenersInitialized is client-only — this documents
the server-side singleton behavior and the intended trade-off.

---

41-48: The popstate listener — a watchful sentinel, yet with a curious delay.

The 50ms setTimeout before refreshing the token on popstate is a heuristic to let cookies settle after navigation. This is somewhat fragile — if the middleware's response hasn't been fully processed, the token read could still be stale. Consider documenting the rationale for the 50ms delay inline for maintainability, so that those who come after may understand why the wizard chose this particular number.

Also, the async callback within setTimeout means any unhandled rejection inside refreshCsrfToken would become an unhandled promise rejection. Though refreshCsrfToken wraps its logic in try/catch, if the catch itself threw, it would be unobserved.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/composables/useCsrfToken.ts` around lines 41 - 48,
The popstate handler uses a 50ms setTimeout before calling
refreshCsrfToken(config) which is a fragile heuristic and the async callback can
surface unhandled rejections; add an inline comment next to the setTimeout
explaining why 50ms was chosen (to allow cookies/middleware-driven Set-Cookie
headers to settle after navigation) and when to revisit it, and change the
callback to explicitly handle promise rejections (e.g. remove the async function
passed to setTimeout and call refreshCsrfToken(config).then(newToken => { if
(newToken && newToken !== csrfToken.value) csrfToken.value = newToken;
}).catch(err => { /* log or ignore safely */ });) so that any errors from
refreshCsrfToken are observed; reference the popstate listener, setTimeout(50),
refreshCsrfToken and csrfToken.value in your update.

packages/nuxt/src/runtime/server/adapter.ts (1)

127-142: Three paths that walk the same road — consider simplifying.

All three content-type branches (form-urlencoded/multipart, JSON/LD+JSON, text/plain) call readBody(event) identically. h3's readBody already handles content-type detection internally. The branching here serves only as documentation for which types are supported, while the else clause (Line 140-141) sets parsedBody = null for unsupported types.

You may wish to collapse this into a single allowlist check for clarity, though I understand the value of explicitness. A small refactor for the Fellowship's future maintainers:

♻️ Optional simplification

       const contentType = getHeader(event, 'content-type') ?? 'text/plain';
       try {
-        if (
-          contentType.startsWith('application/x-www-form-urlencoded') ||
-          contentType.startsWith('multipart/form-data')
-        ) {
-          parsedBody = await readBody(event);
-        } else if (
-          contentType.startsWith('application/json') ||
-          contentType.startsWith('application/ld+json')
-        ) {
-          parsedBody = await readBody(event);
-        } else if (contentType.startsWith('text/plain')) {
+        const supportedTypes = [
+          'application/x-www-form-urlencoded',
+          'multipart/form-data',
+          'application/json',
+          'application/ld+json',
+          'text/plain',
+        ];
+        if (supportedTypes.some((t) => contentType.startsWith(t))) {
           parsedBody = await readBody(event);
         } else {
           parsedBody = null;
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/server/adapter.ts` around lines 127 - 142, The code
repeats identical calls to readBody(event) for multiple content-type branches
(contentType checks) resulting in redundant paths; simplify by replacing the
three identical branches with a single condition that calls readBody(event) when
the contentType is in the supported allowlist (or simply when contentType is
present and not explicitly unsupported) and otherwise sets parsedBody = null,
keeping the variables contentType, parsedBody and the call to readBody(event) in
adapter.ts so behavior is unchanged but the branching is collapsed for clarity.

packages/nextjs/src/client/client.ts (1)

63-65: The fix is correct — a wizard never truncates base64 padding!

Using indexOf + slice instead of the old split('=')[1] properly preserves base64 padding (==) and any = characters embedded in the token value. The guard on eqIndex !== -1, however, is a dead branch: csrfCookie was already matched by .startsWith(${cookieName}=), so indexOf('=') is always > -1.

♻️ Simplify the dead-branch ternary

-    const eqIndex = csrfCookie.indexOf('=');
-    const value = eqIndex !== -1 ? csrfCookie.slice(eqIndex + 1) : '';
-    return decodeURIComponent(value.trim());
+    return decodeURIComponent(csrfCookie.slice(csrfCookie.indexOf('=') + 1).trim());

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nextjs/src/client/client.ts` around lines 63 - 65, The ternary
guarding against eqIndex === -1 is dead because csrfCookie is already validated
with .startsWith(`${cookieName}=`); simplify by removing the conditional and
unconditionally compute the value from the first '=' onward (use
csrfCookie.indexOf('=') to locate it or directly use
csrfCookie.slice(cookieName.length + 1)); update the lines around csrfCookie,
eqIndex, and value in client.ts to return decodeURIComponent of the trimmed
sliced value without the unused branch.

packages/nuxt/src/runtime/composables/useCsrfToken.ts (2)

79-84: There is no need to forge a new ring when one already exists.

This inline type exactly duplicates CsrfArmorPublicConfig defined in ./types.ts. Import and use it instead.

♻️ Proposed fix

+import type { CsrfArmorPublicConfig } from '../types';
 // ...
-  const publicConfig = runtimeConfig.public.csrfArmor as
-    | {
-        cookieName?: string;
-        headerName?: string;
-      }
-    | undefined;
+  const publicConfig = runtimeConfig.public.csrfArmor as
+    | CsrfArmorPublicConfig
+    | undefined;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/composables/useCsrfToken.ts` around lines 79 - 84,
Replace the duplicated inline type for publicConfig in useCsrfToken.ts with the
existing CsrfArmorPublicConfig type from ./types: import CsrfArmorPublicConfig
and change the declared type of publicConfig to runtimeConfig.public.csrfArmor
as CsrfArmorPublicConfig | undefined; update any references to the inline shape
accordingly and remove the inline type block so the code uses the shared
CsrfArmorPublicConfig definition.

---

118-118: Speak plainly; do not say twice what need be said once.

config.headerName is always a non-null string — resolvedConfig unconditionally assigns it at line 89 (?? 'x-csrf-token'). The ?? 'x-csrf-token' on line 118 is unreachable dead code.

♻️ Proposed simplification

-    const headerName = config.headerName ?? 'x-csrf-token';
+    const headerName = config.headerName;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/composables/useCsrfToken.ts` at line 118, The
nullish-coalescing fallback on the local binding is dead code because
resolvedConfig already guarantees a non-null headerName; replace "const
headerName = config.headerName ?? 'x-csrf-token';" with a direct read "const
headerName = config.headerName;" (or use the already resolved value from
resolvedConfig/headerName) to remove the redundant '??' fallback in
useCsrfToken.ts.

packages/nuxt/src/runtime/server/adapter.ts (1)

176-187: Do not carry unnecessary burdens on your journey.

adaptCookieOptions spreads every CookieOptions field unconditionally, including those that are undefined when not set. While h3/cookie-es silently ignores undefined properties during serialization, the explicit undefined keys pollute the returned object and weaken its type contract. Filtering them out is the cleaner approach:

♻️ Proposed fix

-  private adaptCookieOptions(options?: CookieOptions): Record<string, unknown> {
+  private adaptCookieOptions(options?: CookieOptions): Record<string, unknown> {
     if (!options) return {};
 
-    return {
-      secure: options.secure,
-      httpOnly: options.httpOnly,
-      sameSite: options.sameSite,
-      path: options.path,
-      domain: options.domain,
-      maxAge: options.maxAge,
-    };
+    const raw: Record<string, unknown> = {
+      secure: options.secure,
+      httpOnly: options.httpOnly,
+      sameSite: options.sameSite,
+      path: options.path,
+      domain: options.domain,
+      maxAge: options.maxAge,
+    };
+    return Object.fromEntries(Object.entries(raw).filter(([, v]) => v !== undefined));
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/server/adapter.ts` around lines 176 - 187, The
adaptCookieOptions function currently returns all CookieOptions fields even when
undefined; update adaptCookieOptions to omit keys with undefined values so the
returned Record<string, unknown> only contains defined properties (secure,
httpOnly, sameSite, path, domain, maxAge) — e.g., build the object and filter
out undefined entries (using a reduce/Object.entries filter or conditional
assignments) before returning; keep the function name adaptCookieOptions and its
CookieOptions input shape intact and ensure behavior for a missing options
argument still returns {}.

packages/nuxt/src/runtime/plugin.client.ts (1)

22-23: Even a wizard need not cast the same spell twice.

The factory () => token in the useState call (line 22) will never actually run on the client because the state is already hydrated from SSR; the real update is line 23. The factory is therefore dead code here. Simplifying removes the ambiguity:

♻️ Proposed simplification

-  // Shared with useCsrfToken() composable via the same useState key
-  const csrfToken = useState<string | null>('csrf-token', () => token);
-  csrfToken.value = token;
+  // Shared with useCsrfToken() composable via the same useState key.
+  // Factory is intentionally omitted: state is SSR-hydrated (null) and we
+  // always overwrite with the live cookie value on client mount.
+  const csrfToken = useState<string | null>('csrf-token');
+  csrfToken.value = token;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/plugin.client.ts` around lines 22 - 23, The factory
passed to useState is dead code because SSR hydration provides the value and you
then overwrite it on the next line; replace the factory that returns token with
a simple empty initial value and keep the explicit assignment. Specifically,
update the useState call for the 'csrf-token' state (csrfToken and useState) to
use a plain null/empty initial value (e.g., useState<string |
null>('csrf-token', null) or useState<string | null>('csrf-token', () => null))
and leave the existing csrfToken.value = token assignment as-is.

packages/nuxt/test/middleware.test.ts (1)

6-15: Even the smallest gap in armour may let an arrow through.

readBody is included in the vi.mock factory but is never extracted as a typed mock variable (unlike mockedGetHeader, mockedParseCookies, etc.). This means no test currently exercises the body-based token extraction path (getTokenFromRequest priority #3 in the adapter). Consider adding mockedReadBody and a test that submits the CSRF token exclusively in the JSON body.

♻️ Suggested extraction and skeleton test

+const mockedReadBody = vi.mocked(readBody)

Skeleton for the missing path:

+  it('should extract token from JSON body for double-submit', async () => {
+    const adapter = new NuxtAdapter()
+    const protection = createCsrfProtection(adapter, { strategy: 'double-submit' })
+
+    const getEvent = createGetEvent()
+    await protection.protect(getEvent, getEvent)
+    const issuedToken = getResponseHeaders()['x-csrf-token']!
+    vi.clearAllMocks()
+
+    mockedReadBody.mockResolvedValue({ 'csrf-token': issuedToken })
+    const postEvent = createPostEvent(
+      'http://localhost/api',
+      { 'content-type': 'application/json' },
+      { 'csrf-token': issuedToken },
+    )
+    const result = await protection.protect(postEvent, postEvent)
+    expect(result.success).toBe(true)
+  })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/test/middleware.test.ts` around lines 6 - 15, The mock factory
exposes h3.readBody but the test file never extracts it as a typed mock; add a
typed mock variable (e.g. mockedReadBody = vi.mocked(readBody)) alongside
mockedGetHeader/mockedParseCookies and use it in a new test that returns a JSON
body containing only the CSRF token to exercise the body-based extraction path
(getTokenFromRequest / adapter priority `#3`). In the new test, set mockedReadBody
to resolve the token payload, call the middleware/token extraction helper under
test, assert the returned token matches the body value, and remember to
reset/clear mocks between tests.

packages/nuxt/src/runtime/composables/useCsrfToken.ts (2)

16-23: Module-level mutable state shared across SSR requests — safe here, but tread carefully.

resolvedConfig and globalListenersInitialized are module-scoped singletons. In Nuxt SSR, the module is shared across concurrent requests on the server. This is safe because:

• globalListenersInitialized is guarded by import.meta.client (line 34), so it's only mutated on the client.
• resolvedConfig is derived from runtimeConfig.public, which is identical across requests.

A brief inline comment noting why this is safe would spare future travellers from doubt, for not all who wander through module-level state find their way so easily.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/composables/useCsrfToken.ts` around lines 16 - 23,
Add a brief inline comment above the module-level variables explaining why
module-level mutable state is safe here: note that globalListenersInitialized is
only mutated on the client (guarded by import.meta.client) and resolvedConfig is
derived from runtimeConfig.public which is identical across SSR requests, so
concurrent server requests won't cause cross-request state issues; reference the
symbols resolvedConfig and globalListenersInitialized and mention the
runtimeConfig.public origin to clarify for future readers.

---

39-63: The route watcher and the popstate listener both seek the same prize — consider whether both quests are needed.

On browser back/forward navigation, both the watch(route.path) handler (line 41) and the popstate listener (line 51) will fire. The route watcher synchronously reads the cookie, and ~50ms later the popstate handler issues a HEAD request via refreshCsrfToken and potentially overwrites the token again.

Two observations:

1. Redundant update path: The route watcher's synchronous cookie read will be superseded by the popstate handler's async refresh if the token differs. This is benign but may cause a brief flicker in the reactive state.

2. The 50ms delay is a magic number (line 62). On slow connections or heavy server load, the middleware Set-Cookie header may not have settled in 50ms. Consider either extracting this to a named constant with a comment explaining its purpose, or using the route watcher alone (since client-side navigations through Nuxt's router trigger the server middleware, which sets the cookie before the response arrives).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/composables/useCsrfToken.ts` around lines 39 - 63,
The popstate handler duplicates the route watcher: both watch(() => route.path)
using getCsrfToken and the window.addEventListener('popstate') using
refreshCsrfToken race and cause a transient overwrite (and the 50ms is a magic
number). Remove the popstate listener block (the setTimeout + refreshCsrfToken
call) and rely on the existing watch(route.path) + getCsrfToken flow to update
csrfToken.value; if you must keep an async refresh path instead extract the 50
(ms) into a named constant (e.g. CSRF_REFRESH_DELAY_MS) with a comment and
ensure refreshCsrfToken is only invoked when getCsrfToken would produce a
different value to avoid redundant updates.

packages/nuxt/src/runtime/utils/client.ts (1)

1-116: The core logic echoes between realms, yet masquerades in different vestments — consider a shared foundation.

Thou speakest true of duplication, yet the truth is more nuanced than "line-for-line identical." The Nuxt adaptation is nearly half the length of its Next.js counterpart: whilst the Next.js version bears extensive JSDoc with examples and explanatory comments, the Nuxt version stands trimmed to its essence. Yet beneath these surface differences, the logic rings identical.

The functions getCsrfToken, createCsrfHeaders, csrfFetch, and refreshCsrfToken all follow the same paths, differing only in their environment guards (import.meta.client vs. typeof window === 'undefined'). Should one copy receive a bugfix and the other does not, inconsistency shall creep in like shadow at eventide.

Consider extracting the shared logic—cookie parsing, header construction, token management—into @csrf-armor/core, parameterizing only the environment check. Each framework would then wield thin shims atop a single source of truth. This need not impede thy current journey, but I counsel thee: address it ere another adapter joins the fellowship, lest the duplication multiply beyond redemption.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxt/src/runtime/utils/client.ts` around lines 1 - 116, The four
functions getCsrfToken, createCsrfHeaders, csrfFetch and refreshCsrfToken
duplicate logic with only the environment guard differing (import.meta.client);
extract the shared cookie parsing, header construction and token refresh logic
into a single core module (e.g., `@csrf-armor/core`) that exposes pure helpers
(parseCookieToken, buildCsrfHeaders, fetchWithCsrf, refreshToken) and have this
file become a thin shim that only performs the environment check
(import.meta.client) and delegates to those core helpers, passing in config and
any env-specific behavior (like fetch/headers access); update this file to call
the core helpers rather than reimplement logic so future fixes are applied once.